With the advent of 32-bit microprocessors and complex operating software, embedded systems have become very complex systems. The vast majority of electronic products built today include some form of computer hardware executing a stored software program. An embedded system may typically include a microprocessor executing instructions and interacting with an application specific integrated circuit (ASIC) or a custom Integrated Circuit (IC). The microprocessor used in the system is designated herein as a target microprocessor. The external circuitry that interacts with the target microprocessor, whether it is the ASIC, custom IC, or some other form of electronic circuitry, is designated herein as the target circuitry. The combination of the target circuitry and the target microprocessor is designated herein as the target hardware. The software program that is intended to be executed by the target microprocessor is designated herein as the target program.
Given the complexity and density of modern electronics designs, it is desirable that the first system prototype, including the target hardware and the target program, is typically close in form, fit, and function to the end product. The target hardware prototypes would therefore include the ASIC and custom IC designs, which were fabricated and passed their respective qualification and acceptance tests at the foundry.
The target program is typically designed, written, and tested, module by module. The module integration process also involves testing of the integrated software modules. However, because the target hardware may not be available at the time of the software development, it is not possible to test the interaction of the target hardware and the target program. To substitute for the missing target hardware, pieces of the design are "stubbed out," or mockups built to substitute for anticipated missing parts of the target hardware. The term "stubbed out" refers to a mock response to a program call to a location in the yet unbuilt circuitry. The programmer must program a return command that causes the target program to ignore the lack of a true response from the target circuitry. The substitution of mocked up target hardware requires further interpretation of the original hardware design specifications. It is common to find that no single combined software system integration occurs before the software is loaded onto the hardware prototype, let alone tested as a whole (stubbed out or otherwise).
Typically, the hardware and software components of a target system design are brought together for the first time when the prototype target hardware has been fabricated. Because of the prior unavailability of the actual target hardware, one often finds that the target program loaded at the time of the integration of the prototype target hardware and software does not work. It is common to find that the integration problems are strictly due to software complications alone. This may cause a significant delay in the software development due to the problems in the target program. Other problems with the integration may be caused by the interaction of the target hardware with the target program. Consequently, considering the large cost of ASIC and custom IC design, and the relatively low cost ease of software modification, it is common that the software will be force-fitted to the target hardware prototype, thereby increasing the overall planned software development time.
A number of approaches have been developed in an attempt to alleviate or at least minimize the software/hardware integration problems. One approach is to simulate the hardware using a computer hardware simulator. The hardware simulator is a software program that simulates the responses of the target hardware and is implemented entirely in software. Thus, in the hardware simulator, the target hardware and target program are simulated entirely by computer software. The hardware simulation method of verifying the target system is illustrated in FIG. 1. A hardware simulator 20 is a software program that accepts a description of the target hardware, including electrical and logical properties of the target microprocessor and the target circuitry. The target hardware design may be specified graphically by schematic diagrams or by a hardware description language (HDL), such as VHDL. The hardware simulator 20 is a commercially available product that includes a target program 22 that is compiled into object code, and the object code is downloaded into a processor memory model 24 within the hardware simulator 20. A processor functional model 26 is a software description, including the electrical and logical properties, of the target microprocessor, while a target circuitry functional model 28 provides a model of the target circuitry, such as an ASIC, or other custom or semi-custom design. The hardware simulator 20 allows the processor functional model 26 to simulate execution of the target program 22 event by event. The processor functional model 26 and the target circuitry functional model 28 can be specified to various levels of abstraction by a conventional HDL.
There are disadvantages in using the hardware simulator 20 to simulate the target hardware. Microprocessor manufacturers are cautious about providing the full-functional processor model 26 that could be reverse-engineered into a competitive product. In addition, the full-functional processor model 26 can be extremely detailed for a complex circuit such as the target microprocessor resulting in the execution time required to simulated the full-functional processor model 26 adding significantly to the simulation run-times. Another disadvantage is that the target program 22 can be quite long, which leads to the additional burden of trying to run longer simulation required for larger target program 22 into the processor memory model 24 can consume large amounts of system resources, and simulation run time can become unacceptably long. Typical simulation speeds may only reach 2-4 microprocessor instructions per second. Also, if the target program 22 malfunctions, then the programmer has the unenviable task of debugging the target program typically without the aid of debuggers or any other software design and analysis tools.
Another approach is a form of software simulation of the target hardware using an instruction set simulator (ISS) 40, illustrated in FIG. 2. The ISS 40 includes a memory 42 that contains the target program 22. The ISS 40 strives to guarantee functional accuracy of both instruction functions and memory references only at the processor instruction level. As a result, accuracy to detailed internal timing is sacrificed for speed. The speed of a typical ISS 40 is on the order of 1,000-10,000 microprocessor instructions per second. The ISS 40 executes the target program 44, but has only limited visibility to circuitry outside of the target microprocessor. The typical ISS 40 does not represent any custom target circuitry in simulation beyond a register reference, and hence is of limited value to hardware designers or software designers that are concerned with interactions with custom hardware.
These first two approaches simulate the target hardware completely in software. As known by those of ordinary skill in the art, total software simulation of the target hardware offers relatively low cost and flexibility. However, such a total software simulation suffers from the disadvantages that the target hardware often cannot be completely modeled without unacceptably long run-times.
A third approach, which alleviates the unacceptably long run-times encountered with the processor functional model 26 (see FIG. 1), is to replace the processor functional model in the hardware simulator 20 with a physical integrated circuit (IC) microprocessor 50, as illustrated in FIG. 3. The microprocessor 50 is connected to the hardware simulator 20 via a hardware modeler 52. The target program 22 is contained in the memory model 24 in the hardware simulator 20, and all instructions are executed out of the memory model 24, as previously discussed with respect to FIG. 1. The microprocessor 50 may be the actual target microprocessor or other circuit to simulate the behavior of the target microprocessor. It should be noted that the physical microprocessor 50 and the hardware modeler 52 are hardware components rather than software simulations. The cost of the typical hardware modeler 52 can be quite high, ranging from $40,000 to over $200,000.
A similar approach illustrated in FIG. 4 uses a device known as a processor emulator 60 to model the target processor. The processor emulator 60 is a hardware device that substitutes for the target microprocessor. Processor emulators are conventional devices presently available from sources such as Applied Microsystems Corporation. The processor emulator 60 includes a microprocessor 76, which is typically the target processor. The processor emulator 60 may also include an emulator memory 78 and a control circuit 80. The processor emulator 60 is coupled to a workstation 84 or computer terminal by a communications link 86. The workstation 84 may be a stand-alone computer workstation or simply a terminal coupled to a computer (not shown) to which the processor emulator 60 is also coupled. User interface software 88 within the workstation 84 controls the display of data on the workstation and permits user input to the emulator. The user interface software 88 and the control circuit 80 of the processor emulator 60 are conventional components of the processor emulator and add supplemental control to the prototype hardware system.
The processor emulator is coupled to an actual target system 62 having a memory 66 containing the target program 22, and a socket 70 for the target microprocessor. The processor emulator 60 is coupled to the target system 62 of the target hardware by a bus system 72 and typically plugs directly into the socket 70 as a substitute for the target microprocessor. The emulator memory 78 contains an emulator control program independent of the target program 22 in the memory 66. However, the target program 22 can also be loaded into the emulator memory 78 in what is sometimes called a memory overlay. Thus, the target program 22 can be executed from the memory 66, the emulator memory 78, or both. Execution of the target program 22 only from the emulator memory 78 allows execution of the target program without the benefit of software interaction with the target circuitry.
Instead of plugging into the actual target system 62 as shown in FIG. 4, the processor emulator 60 may interface with reconfigurable circuitry 96 as shown in FIG. 5. The reconfigurable circuitry 96 may be a field-programmable gate array (FPGA) which emulates target circuitry functions including the ASIC or custom IC. Companies such as Quickturn and Aptix have developed hardware circuit emulators which allow hardware designs to be downloaded into the reconfigurable circuitry 96 and mounted on a board-like device. As before, the hardware circuit emulator 60 includes a processor 76 and a memory 78. The target program 22 is stored in the memory 78 of the emulator 60 so that it can be executed by the processor 76. This approach, known as hardware circuit emulation, allows the target system to be tested as if it is already built. Hardware circuit emulation has the advantages of speed and early breadboard fabrication. However, high cost and tedium in configuration and debugging limit their application. These tools also lack hardware-software debugging visibility because access to internal registers and memory locations is not available. Also, the hardware circuit emulator 94 typically represent a major investment on the user's part, in both design effort and capital cost.
A final approach basically combines the use of the processor emulator 60 of FIGS. 4 and 5 with the target circuitry model 28 in the hardware simulator 20 of FIG. 3. This approach essentially substitutes the processor emulator 60 for the hardware modeler 52 shown in FIG. 3 except that the target program is executed out of the emulator memory 78. With reference to FIG. 6, this prior art approach couples the processor emulator 60 to an engineering workstation 100 simulating the target circuitry using a target circuitry model 28 through a communications interface 102. The workstation 100 with its target circuitry model 28 is thus a hardware simulator 104. The communications interface 102 provides communication between the processor emulator 60 and the hardware simulator 104 only when an event, either in the target program 22 or in the software simulation of the target circuit, requires interaction of the target program 22 and simulated target circuit. Thus, the processor emulator 60 and hardware simulator 104 are synchronized only when an event requires interaction between the two.
Each of the above-described approaches has advantages and disadvantages. Therefore, it can be appreciated that there is a significant need for a system that allows complete testing of the target hardware and software with efficiency and low cost. The present invention provides this and other advantages, as will be illustrated by the following description and accompanying figures.